Issuer metadata to indicate PoP requirement. #87

cobward · 2023-10-19T08:38:08Z

Addresses #89

Currently a wallet has no way of knowing whether the issuing authority requires a proof of possession in the Credential Request. From my point of view there are two ways we can remedy this:

Add a parameter in the credentials_supported issuer metadata object that indicates whether a PoP is required.
Add some normative text which would require wallets to send a PoP if proof_types_supported in the credentials_supported issuer metadata object is not omitted and contains at least one element.

Personally I prefer explicit indication over implied so I have raised this PR showing option 1, but I am open to other opinions and options.

paulbastian · 2023-10-26T10:46:11Z

There is also the option, that the Wallet may know this implicit, depending on whether the Issuer sends a c_nonce in the Token Response. But I think putting it in the Issuer metadata is the right direction, as there may also be more requirements on the keys and other requirements such as wallet attestations that must be reflected in the metadata

openid-4-verifiable-credential-issuance-1_0.md

Sakurann · 2023-11-01T21:13:44Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -1177,6 +1177,7 @@ This section defines the structure of the objects that appear in the `credential
 * `cryptographic_binding_methods_supported`: OPTIONAL. Array of case sensitive strings that identify how the Credential is bound to the identifier of the End-User who possesses the Credential as defined in (#credential-binding). Support for keys in JWK format [@!RFC7517] is indicated by the value `jwk`. Support for keys expressed as a COSE Key object [@!RFC8152] (for example, used in [@!ISO.18013-5]) is indicated by the value `cose_key`. When Cryptographic Binding Method is a DID, valid values MUST be a `did:` prefix followed by a method-name using a syntax as defined in Section 3.1 of [@!DID-Core], but without a `:`and method-specific-id. For example, support for the DID method with a method-name "example" would be represented by `did:example`. Support for all DID methods listed in Section 13 of [@DID_Specification_Registries] is indicated by sending a DID without any method-name.
 * `cryptographic_suites_supported`: OPTIONAL. Array of case sensitive strings that identify the cryptographic suites that are supported for the `cryptographic_binding_methods_supported`. Cryptographic algorithms for Credentials in `jwt_vc` format should use algorithm names defined in [IANA JOSE Algorithms Registry](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms). Cryptographic algorithms for Credentials in `ldp_vc` format should use signature suites names defined in [Linked Data Cryptographic Suite Registry](https://w3c-ccg.github.io/ld-cryptosuite-registry/).
 * `proof_types_supported`: OPTIONAL. A JSON array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports. Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, the default value is `jwt`. `proof_type` claim is defined in (#credential_request).
+* `proof_of_possession_required`: OPTIONAL. A JSON boolean that indicates whether a proof of possession must be submitted when requesting a credential of this format. If this field is omitted it can assumed to be `false`.


Suggested change

* `proof_of_possession_required`: OPTIONAL. A JSON boolean that indicates whether a proof of possession must be submitted when requesting a credential of this format. If this field is omitted it can assumed to be `false`.

* `proof_of_possession_required`: OPTIONAL. Boolean value specifying whether Credential Issuer requires a proof of possession to be submitted in the Credential Request, with `true` indicating support. If omitted, the default value is `true`.

aligning with the rest of the language. also, why is default false..?

tlodderstedt

Agree with Kristina to fold the newly proposed metadata claim into the existing one and change its name

Sakurann

discussed in a WG call. agreed that there is a need to clarify when PoP is needed but with an improvement. Specific suggestion is as following:
there are currently two parameters: proof_types_supported and proof_of_possession_required. the presence of proof_types_supported alone can be used to indicate that PoP is required because for the same credential type, PoP is either required or not (no use-case when same type is sometimes issued without PoP and other times with PoP), but _supported has a different nuance from _required so suggetion is to rename proof_types_supported to proof_types and clarify that when it is omitted, it means "PoP not required".

Sakurann · 2023-11-23T16:18:51Z

openid-4-verifiable-credential-issuance-1_0.md

  * `proof_types_supported`: OPTIONAL. A JSON array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports. Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, the default value is `jwt`. `proof_type` claim is defined in (#credential_request).
+  * `proof_of_possession_required`: OPTIONAL. Boolean value specifying whether Credential Issuer requires a proof of possession to be submitted in the Credential Request, with `true` indicating support. If this field is omitted it can assumed to be `false`.


merge into one parameter proof_types, where if omitted, the default value is PoP not required.

Suggested change

* `proof_types_supported`: OPTIONAL. A JSON array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports. Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, the default value is `jwt`. `proof_type` claim is defined in (#credential_request).

* `proof_of_possession_required`: OPTIONAL. Boolean value specifying whether Credential Issuer requires a proof of possession to be submitted in the Credential Request, with `true` indicating support. If this field is omitted it can assumed to be `false`.

* `proof_types`: REQUIRED when Credential Issuer requires a proof of possession of the cryptographic key material to be submitted in the Credential Request. Array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports as defined in (#credential_request). Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, Credential Issuer does not require proof of possession of the cryptographic key material.

something like this?

@Sakurann your suggestions looks good to me.

Sakurann · 2023-11-23T16:19:31Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -710,7 +710,7 @@ For cryptographic binding, the Client has the following options to provide crypt
 A Client makes a Credential Request to the Credential Endpoint by sending the following parameters in the entity-body of an HTTP POST request using the `application/json` media type.

 * `format`: REQUIRED when the `credential_identifier` was not returned from the Token Response. MUST NOT be used otherwise. String that determines the format of the Credential to be issued, which may determine the type and any other information related to the Credential to be issued. Credential Format Profiles consisting of the Credential format specific set of parameters are defined in (#format_profiles). When this parameter is used, `credential_identifier` parameter MUST NOT be present.
-* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to.  The `proof` object MUST contain a following claim:
+* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to.  The `proof` object is REQUIRED if the `proof_of_possession_required` parameter in the issuer metadata for the submitted credential format is `true`. The `proof` object MUST contain a following claim:


Suggested change

* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to. The `proof` object is REQUIRED if the `proof_of_possession_required` parameter in the issuer metadata for the submitted credential format is `true`. The `proof` object MUST contain a following claim:

* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to. The `proof` object is REQUIRED if the `proof_types` parameter is present in the issuer metadata. The `proof` object MUST contain a following claim:

aligning with below

cobward · 2023-12-04T06:20:27Z

@Sakurann I've made some changes based on your suggestions, but I tried to streamline the language a little.

Sakurann

would like to be more explicit when parameter is omitted

Sakurann · 2023-12-07T00:45:28Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -1196,7 +1196,7 @@ This specification defines the following Credential Issuer Metadata:
  * `scope`: OPTIONAL. A JSON string identifying the scope value that this Credential Issuer supports for this particular Credential. The value can be the same accross multiple `credentials_supported` objects. The Authorization Server MUST be able to uniquely identify the Credential Issuer based on the scope value. The Wallet can use this value in the Authorization Request as defined in (#credential-request-using-type-specific-scope). Scope values in this Credential Issuer metadata MAY duplicate those in the `scopes_supported` parameter of the Authorization Server.
  * `cryptographic_binding_methods_supported`: OPTIONAL. Array of case sensitive strings that identify how the Credential is bound to the identifier of the End-User who possesses the Credential as defined in (#credential-binding). Support for keys in JWK format [@!RFC7517] is indicated by the value `jwk`. Support for keys expressed as a COSE Key object [@!RFC8152] (for example, used in [@!ISO.18013-5]) is indicated by the value `cose_key`. When Cryptographic Binding Method is a DID, valid values MUST be a `did:` prefix followed by a method-name using a syntax as defined in Section 3.1 of [@!DID-Core], but without a `:`and method-specific-id. For example, support for the DID method with a method-name "example" would be represented by `did:example`. Support for all DID methods listed in Section 13 of [@DID_Specification_Registries] is indicated by sending a DID without any method-name.
  * `cryptographic_suites_supported`: OPTIONAL. Array of case sensitive strings that identify the cryptographic suites that are supported for the `cryptographic_binding_methods_supported`. Cryptographic algorithms for Credentials in `jwt_vc` format should use algorithm names defined in [IANA JOSE Algorithms Registry](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms). Cryptographic algorithms for Credentials in `ldp_vc` format should use signature suites names defined in [Linked Data Cryptographic Suite Registry](https://w3c-ccg.github.io/ld-cryptosuite-registry/).
-  * `proof_types_supported`: OPTIONAL. A JSON array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports. Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, the default value is `jwt`. `proof_type` claim is defined in (#credential_request).
+  * `proof_types`: OPTIONAL. Array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports as defined in (#credential_request). If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material.


Suggested change

* `proof_types`: OPTIONAL. Array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports as defined in (#credential_request). If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material.

* `proof_types`: OPTIONAL. Array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports as defined in (#credential_request), one of which is MUST be used in the Credential Request. If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material. If the parameter is omitted or array is empty, Credential Issuer does not require proof of possession of the cryptographic key material.

No need to be explicit what to do when PoP is not present..?

I think "supports" needs to be changed to "requires" as this is the semantics of the array.

"If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material."

discussed in the Dec-7-2023 WG. agreed to merge once this suggestion is accepted.

tlodderstedt · 2023-12-07T12:48:13Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -1196,7 +1196,7 @@ This specification defines the following Credential Issuer Metadata:
  * `scope`: OPTIONAL. A JSON string identifying the scope value that this Credential Issuer supports for this particular Credential. The value can be the same accross multiple `credentials_supported` objects. The Authorization Server MUST be able to uniquely identify the Credential Issuer based on the scope value. The Wallet can use this value in the Authorization Request as defined in (#credential-request-using-type-specific-scope). Scope values in this Credential Issuer metadata MAY duplicate those in the `scopes_supported` parameter of the Authorization Server.
  * `cryptographic_binding_methods_supported`: OPTIONAL. Array of case sensitive strings that identify how the Credential is bound to the identifier of the End-User who possesses the Credential as defined in (#credential-binding). Support for keys in JWK format [@!RFC7517] is indicated by the value `jwk`. Support for keys expressed as a COSE Key object [@!RFC8152] (for example, used in [@!ISO.18013-5]) is indicated by the value `cose_key`. When Cryptographic Binding Method is a DID, valid values MUST be a `did:` prefix followed by a method-name using a syntax as defined in Section 3.1 of [@!DID-Core], but without a `:`and method-specific-id. For example, support for the DID method with a method-name "example" would be represented by `did:example`. Support for all DID methods listed in Section 13 of [@DID_Specification_Registries] is indicated by sending a DID without any method-name.
  * `cryptographic_suites_supported`: OPTIONAL. Array of case sensitive strings that identify the cryptographic suites that are supported for the `cryptographic_binding_methods_supported`. Cryptographic algorithms for Credentials in `jwt_vc` format should use algorithm names defined in [IANA JOSE Algorithms Registry](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms). Cryptographic algorithms for Credentials in `ldp_vc` format should use signature suites names defined in [Linked Data Cryptographic Suite Registry](https://w3c-ccg.github.io/ld-cryptosuite-registry/).
-  * `proof_types_supported`: OPTIONAL. A JSON array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports. Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, the default value is `jwt`. `proof_type` claim is defined in (#credential_request).
+  * `proof_types`: OPTIONAL. Array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports as defined in (#credential_request). If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material.


I think "supports" needs to be changed to "requires" as this is the semantics of the array.

"If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material."

cobward · 2023-12-12T18:15:42Z

This is how the text currently reads:

Array of case sensitive strings, each representing a proof_type that the Credential Issuer supports as defined in (#credential_request), one of which MUST be used in the Credential Request. If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material. If the parameter is omitted or array is empty, Credential Issuer does not require proof of possession of the cryptographic key material.

I didn't quite understand your comment Torsten. Do you want the highlighted word to be changed from supports to requires?

Sakurann · 2023-12-13T12:49:46Z

If you accepted my suggestion, @tlodderstedt agreed during the WG call that the language suggested addressed his concerns.

I think a sentence quoted in Torsten's comment is not the one he meant - and he was looking to clarify if the wallet need to support all or at least one of the proof types supported by the issuer.

so this one should be good to go - thank you, Jacob!

cobward · 2023-12-13T15:14:56Z

If you accepted my suggestion, @tlodderstedt agreed during the WG call that the language suggested addressed his concerns.

I think a sentence quoted in Torsten's comment is not the one he meant - and he was looking to clarify if the wallet need to support all or at least one of the proof types supported by the issuer.

so this one should be good to go - thank you, Jacob!

Great, thanks for clearing that up Kristina

openid-4-verifiable-credential-issuance-1_0.md

tplooker

Approved with one minor editorial nit

Co-authored-by: Tobias Looker <[email protected]>

tlodderstedt · 2023-12-14T07:04:00Z

openid-4-verifiable-credential-issuance-1_0.md

@@ -713,7 +713,7 @@ For cryptographic binding, the Client has the following options to provide crypt
 A Client makes a Credential Request to the Credential Endpoint by sending the following parameters in the entity-body of an HTTP POST request using the `application/json` media type.

 * `format`: REQUIRED when the `credential_identifier` was not returned from the Token Response. MUST NOT be used otherwise. String that determines the format of the Credential to be issued, which may determine the type and any other information related to the Credential to be issued. Credential Format Profiles consisting of the Credential format specific set of parameters are defined in (#format_profiles). When this parameter is used, `credential_identifier` parameter MUST NOT be present.
-* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to.  The `proof` object MUST contain a following claim:
+* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to.  The `proof` object is REQUIRED if the `proof_types` parameter is non-empty and present in the `credentials_supported` map of the issuer metadata for the requested credential. The `proof` object MUST contain a following claim:


Suggested change

* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to. The `proof` object is REQUIRED if the `proof_types` parameter is non-empty and present in the `credentials_supported` map of the issuer metadata for the requested credential. The `proof` object MUST contain a following claim:

* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to. The `proof` object is REQUIRED if the `proof_types` parameter is present in the `credentials_supported` map of the issuer metadata for the requested credential and non-empty. The `proof` object MUST contain a following claim:

cobward mentioned this pull request Oct 19, 2023

Issuer indication of PoP requirement in Credential Request. #89

Closed

peppelinux mentioned this pull request Oct 26, 2023

DPoP as mandatory with interop guidances italia/eudi-wallet-it-docs#149

Closed

peppelinux reviewed Oct 28, 2023

View reviewed changes

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved

Sakurann reviewed Nov 1, 2023

View reviewed changes

cobward force-pushed the patch-1 branch from bb221ee to 22d80a5 Compare November 20, 2023 12:08

cobward requested a review from Sakurann November 21, 2023 14:35

tlodderstedt approved these changes Nov 23, 2023

View reviewed changes

tlodderstedt requested changes Nov 23, 2023

View reviewed changes

Sakurann reviewed Nov 23, 2023

View reviewed changes

Based on latest suggested language.

193ec52

cobward force-pushed the patch-1 branch from 3a779ff to 193ec52 Compare December 4, 2023 06:15

Specify what should happen if array is empty

41d6217

cobward requested review from Sakurann and tlodderstedt December 4, 2023 06:20

jogu approved these changes Dec 4, 2023

View reviewed changes

Sakurann requested review from danielfett and peppelinux December 7, 2023 00:42

Sakurann approved these changes Dec 7, 2023

View reviewed changes

Sakurann added this to the ID-1 milestone Dec 7, 2023

peppelinux approved these changes Dec 7, 2023

View reviewed changes

tlodderstedt requested changes Dec 7, 2023

View reviewed changes

cobward requested a review from tlodderstedt December 12, 2023 18:11

Add explicit language around semantics of array

6cefd32

cobward force-pushed the patch-1 branch from 068a4e4 to 6cefd32 Compare December 12, 2023 18:15

tplooker reviewed Dec 13, 2023

View reviewed changes

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved

tplooker approved these changes Dec 13, 2023

View reviewed changes

Tobias' editorial nit

1845974

Co-authored-by: Tobias Looker <[email protected]>

tlodderstedt approved these changes Dec 14, 2023

View reviewed changes

paulbastian approved these changes Dec 14, 2023

View reviewed changes

Sakurann merged commit 32c146c into openid:main Dec 14, 2023
2 checks passed

cobward deleted the patch-1 branch December 14, 2023 21:50

jogu mentioned this pull request Dec 28, 2023

Wallet can't always identity whether key proof is required #175

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issuer metadata to indicate PoP requirement. #87

Issuer metadata to indicate PoP requirement. #87

cobward commented Oct 19, 2023 •

edited

Loading

paulbastian commented Oct 26, 2023

Sakurann Nov 1, 2023

tlodderstedt left a comment

Sakurann left a comment

Sakurann Nov 23, 2023

jogu Nov 23, 2023

Sakurann Nov 23, 2023

cobward commented Dec 4, 2023

Sakurann left a comment

Sakurann Dec 7, 2023 •

edited

Loading

tlodderstedt Dec 7, 2023

Sakurann Dec 7, 2023

tlodderstedt Dec 7, 2023

cobward commented Dec 12, 2023

Sakurann commented Dec 13, 2023 •

edited

Loading

cobward commented Dec 13, 2023

tplooker left a comment

tlodderstedt Dec 14, 2023

	* `proof_of_possession_required`: OPTIONAL. A JSON boolean that indicates whether a proof of possession must be submitted when requesting a credential of this format. If this field is omitted it can assumed to be `false`.
	* `proof_of_possession_required`: OPTIONAL. Boolean value specifying whether Credential Issuer requires a proof of possession to be submitted in the Credential Request, with `true` indicating support. If omitted, the default value is `true`.

		* `proof_types_supported`: OPTIONAL. A JSON array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports. Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, the default value is `jwt`. `proof_type` claim is defined in (#credential_request).
		* `proof_of_possession_required`: OPTIONAL. Boolean value specifying whether Credential Issuer requires a proof of possession to be submitted in the Credential Request, with `true` indicating support. If this field is omitted it can assumed to be `false`.

	* `proof_types_supported`: OPTIONAL. A JSON array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports. Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, the default value is `jwt`. `proof_type` claim is defined in (#credential_request).
	* `proof_of_possession_required`: OPTIONAL. Boolean value specifying whether Credential Issuer requires a proof of possession to be submitted in the Credential Request, with `true` indicating support. If this field is omitted it can assumed to be `false`.
	* `proof_types`: REQUIRED when Credential Issuer requires a proof of possession of the cryptographic key material to be submitted in the Credential Request. Array of case sensitive strings, each representing `proof_type` that the Credential Issuer supports as defined in (#credential_request). Supported values include those defined in (#proof_types) or other values defined in a profile of this specification or elsewhere. If omitted, Credential Issuer does not require proof of possession of the cryptographic key material.

	* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to. The `proof` object is REQUIRED if the `proof_of_possession_required` parameter in the issuer metadata for the submitted credential format is `true`. The `proof` object MUST contain a following claim:
	* `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to. The `proof` object is REQUIRED if the `proof_types` parameter is present in the issuer metadata. The `proof` object MUST contain a following claim:

Issuer metadata to indicate PoP requirement. #87

Issuer metadata to indicate PoP requirement. #87

Conversation

cobward commented Oct 19, 2023 • edited Loading

paulbastian commented Oct 26, 2023

Choose a reason for hiding this comment

tlodderstedt left a comment

Choose a reason for hiding this comment

Sakurann left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cobward commented Dec 4, 2023

Sakurann left a comment

Choose a reason for hiding this comment

Sakurann Dec 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cobward commented Dec 12, 2023

Sakurann commented Dec 13, 2023 • edited Loading

cobward commented Dec 13, 2023

tplooker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cobward commented Oct 19, 2023 •

edited

Loading

Sakurann Dec 7, 2023 •

edited

Loading

Sakurann commented Dec 13, 2023 •

edited

Loading